@t-bast does this look like a reasonable approach to integrating the max_excess functionality into our funding flow?

As discussed offline, I don't think we'll want to merge this change for single-funded channel. For simplicity, we should only apply this strategy to dual-funded channels and splicing, which both currently use a similar funding flow (based on the InteractiveTxFunder) and will thus probably use the same design to handle excess. On top of that, we'll be deprecating the single-funded channels flow once enough nodes support dual funding, so it doesn't make much sense to have code churn on it now.

I'm not sure we'll be able to do something similar to what you've done for single-funded channels. I think the design should be that we spawn an InteractiveTxFunder outside of the InteractiveTxBuilder, before sending open_channel2 / accept_channel2 / splice_init / splice_ack whenever we want to contribute to the transaction, and then inject the resulting inputs/outputs when creating the InteractiveTxBuilder, but I haven't looked at the code changes that will be necessary to allow that.

I'm not sure we'll be able to do something similar to what you've done for single-funded channels. I think the design should be that we spawn an InteractiveTxFunder outside of the InteractiveTxBuilder, before sending open_channel2 / accept_channel2 / splice_init / splice_ack whenever we want to contribute to the transaction, and then inject the resulting inputs/outputs when creating the InteractiveTxBuilder, but I haven't looked at the code changes that will be necessary to allow that.

This is what I've been investigating - one aspect of dual funding that I can't seem to work around is that the initiator doesn't know whether or not to include unconfirmed inputs until after we receive 'accept_channel2' and check the 'requireConfirmedInputs' tlv.

Another approach is to create a workflow where we can abort and restart the dual-funded open or splice with the correct inputs locked if we find the local contribution should be increased to avoid a change output. Do you think something like that would be acceptable as a solution?

I need to investigate your RBF PR to better understand how that works, but I think we'll need a different approach to handle changing the local contribution for RBF.

Another idea is adding a tlv to the tx_add_input message that changes the local contribution previously set by open_channel2 (or accept_channel2). If the other side doesn't support that tlv it would cause the flow to break after tx_complete, which is ugly.

Another idea is adding a tlv to the tx_add_input message that changes the local contribution previously set by open_channel2 (or accept_channel2). If the other side doesn't support that tlv it would cause the flow to break after tx_complete, which is ugly.

I don't think this is a good idea: it clearly won't be accepted in the BOLTs, and is probably a can of worms to implement correctly.

This is what I've been investigating - one aspect of dual funding that I can't seem to work around is that the initiator doesn't know whether or not to include unconfirmed inputs until after we receive 'accept_channel2' and check the 'requireConfirmedInputs' tlv.

I don't think this is a big issue: we can use a heuristic to "guess" what our peer will set in accept_channel2 / splice_ack. Or we can restrict ourselves to only use confirmed inputs when we're the opener/splicer, which is safer.

Note that this is only an issue when we are sending open_channel2 / splice_init. But an important point with dual funding and liquidity ads is that we potentially want to add inputs when we receive open_channel2 / splice_init (which is the main scenario for LSPs where people purchase liquidity): in that case there's no problem, we have our peer's parameters. It's probably worth taking a look at #2848, which will likely be added to master before this excess feature. You can also take a look at the on-the-fly funding proposal to see the whole protocol flow: #2861.

Another approach is to create a workflow where we can abort and restart the dual-funded open or splice with the correct inputs locked if we find the local contribution should be increased to avoid a change output. Do you think something like that would be acceptable as a solution?

This would be very hacky and I don't think it works well in practice: you'd need to be able to correctly pipe that information between the interactive-tx session created by the channel to the peer, which is likely hard to get right. You'd also need to keep inputs locked while you're doing this, but handle all potential error cases to unlock them (otherwise we'd end up with permanently locked utxos which is a serious issue).

I don't think we should merge this for single-funded channel, let's focus on #2903 only instead.